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Integrating  a  Test  and  Training  Enabling  Architecture  (TENA)  application  into  this  exercise  was 
done  within  a  very  tight  schedule  (in  less  than  two  weeks).  The  level  of  completion  would  have 
been  impossible  were  it  not  for  the  efforts  and  assistance  of  Alan  Scramlin  and  Anthony  Docimo 
of  the  U.S.  Army  Aberdeen  Test  Center  (ATC).  Mr.  Scramlin  continues  even  now  to  work  on 
the  TENA  “switch”  that  will  facilitate  future  TENA  object  model  changes  and  allow  these 
revised  object  models  to  be  integrated  into  the  ATC  Advanced  Distributed  Modular  Acquisition 
System  (ADMAS)  production  system.  The  instrumentation  development  team  also  provided  the 
Virtual  Proving  Ground  (VPG)  team  with  a  TENA  development  workstation  in  the  Microsoft 
Windows1  XP  environment.  Mr.  Docimo  had  already  completed  the  translocation  algorithm  and 
applied  it  during  the  VPG  distributed  test  event  (DTE)  4  held  in  August  2004.  This  reduced 
much  of  the  work  to  “porting”  the  code  into  the  Windows  environment  and  integrating  it  with  the 
TENA  application.  Gerry  Hinkle  and  Manfred  (Fred)  Hartman  of  ATC  cleared  a  path  through 
network  firewalls  and  identified  computer  connectivity  issues,  making  it  possible  to  interact  with 
other  Army  test  centers  across  the  continental  United  States. 
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1.  Purpose 


This  summary  describes  the  recently  completed  virtual  proving  ground  (VPG)  architecture  focus 
group  distributed  test  exercise  event  and  specifically,  the  U.S.  Army  Aberdeen  Test  Center’s 
(ATC’s)  role,  goals,  and  accomplishments.  Possible  future  courses  of  action  for  ATC  direction 
are  discussed  as  recommendations. 


2.  Overview 


For  those  who  are  reasonably  familiar  with  the  VPG  project  and  its  architecture  focus  group 
activities,  reading  section  3  and  the  related  section  7  should  be  sufficient.  The  other  sections  of 
this  document  provide  further  details  and  background  infonnation.  A  short,  high  level  overview 
VPG  architecture  integration  evaluation  is  provided  in  section  4.  ATC  immediate  objectives  for 
the  current  integration  effort  are  reviewed  in  section  5  and  to  what  extent  they  were  achieved  is 
explained  in  section  6.  Recommendations  specific  to  ATC  and  more  generally,  distributed 
testing  and  simulation,  are  presented  in  sections  7  and  8. 


3.  Developmental  Test  and  Evaluation  Architecture  (DTE  ARCH)  Milestone 
(MS)  4  Overview  and  Background 


The  U.S.  Army  Test  and  Evaluation  Command  is  planning  on  installing  a  permanent,  secure, 
distributed  infrastructure  capability  that  can  be  used  to  support  test  and  evaluation  throughout  the 
acquisition  life  cycle.  It  is  necessary  to  understand  technical  issues  facing  this  vision.  DTE 
ARCH  integration  activities  are  one  of  the  means  by  which  the  Developmental  Test  Command 
(DTC)  can  explore  distributed  testing  functionality  provided  by  Test  and  training  ENabling 
Architecture  (TENA)  and  various  test  range  resources.  DTE  ARCH  integration  efforts  have 
three  primary  objectives  (2): 

1 .  Characterize  network  parameters  relative  to  distributed  testing, 

2.  Characterize  the  middleware,  i.e.,  TENA, 

3.  Incorporate  a  broad  range  of  test  assets  and  characterize  the  object  model  design. 
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During  integration  of  MS  4,  the  network  could  not  be  characterized  because  of  a  lack  of 
resources  for  tools  and  execution.  The  major  focus  of  DTE  ARCH  MS  4  was  to  gain  a  better 
assessment  of  TENA  and  application  of  test  asset  object  models  (objectives  2  and  3)  as  they 
support  distributed  testing.  This  involved  connectivity  testing  and  execution  of  a  few  operational 
test  scenarios  designed  to  exercise  TENA  as  well  as  final  application  functionality. 

DTE  ARCH  MS  4  was  the  most  recent  in  a  series  of  functional  tests,  each  building  upon  the 
integration  capability  of  the  previous  milestones.  Earlier  milestone  events  established  each  test 
center’s  basic  ability  to  run  TENA  stateful  (2)  distributed  objects  (SDOs)2  in  a  local  area  and 
wide  area  network  environment.  These  were  simple  applications  prepared  by  White  Sands 
Missile  Range  (WSMR)  personnel.  Later  milestones  such  as  MS  4  involved  each  test  center 
preparing  their  own  TENA  SDO  that  was  germane  to  their  commodity  area.  A  U.S.  Army 
Training  and  Doctrine  Command  (TRADOC)-based  operation  test  scenario  that  is  depicted  in 
figure  1  and  outlined  in  the  test  center  narratives,  and  test  execution  sequence  (appendices  A  and 
B)  was  used  as  a  basis  to  drive  the  simulations  and  tools  involved.  More  details  about  the 
scenario  are  given  in  reference  (2). 


SUT 

(System  Under  Test) 

ORION 

DAS 

Flight  Lab 

Vehicle  Control  System 
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Vehicle  DAS  (ADMAS) 
IR 

Terrain 
Weather 

BDA  Sensor  -  MIRSP, 
NLOS  DAS 
Control  (Starship) 

SAF  / 


Example 
M&S  Tools 
supporting 
SUT 
Testing 


Assumption:  Target  has  been  identified. 
Scenario: 

Vehicle  in  a  UA  going  from  pt  a  b 
NLOS  Firing  from  vehicle 
Aircraft  to  BDA 

C2  Station  (RPWS)  talk  to  platforms 

Sensors: 

IR  to  do  BDA  piece 


C2  Node 


BDA  Sensor 


Test 

Test 

Data 
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Figure  1.  DTE  ARCH  scenario  operational  view  (figure  1  of  reference  1). 
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“  SDO  -  a  term  used  to  describe  a  TENA  application. 
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4.  ATC  Objectives 


1.  ATC  was  to  integrate  an  advanced  distributed  modular  acquisition  system  (ADMAS)  TENA 
component  and  represent  vehicle  position  on  the  WSMR  virtual  terrain  (appendix  A).  Vehicle 
platform  position  would  be  read  chiefly  by  the  One  Semi-automated  Forces  (OneSAF)  test  bed 
baseline  (OTB)  (3). 

Other  objectives  that  were  expressed  verbally  ( 4 )  were  to 

2.  Include  global  positioning  system  (GPS)  (time  synchronization)  on  each  workstation 
involved.  The  intent  was  to  provide  a  synchronized  time  stamp. 

•  ATC  did  not  execute  a  time  stamp  because  (a)  a  GPS  timing  source  could  not  be  found  in 
time  for  MS  4,  (b)  at  the  time  it  was  not  clear  where  and  in  which  object  model  (application 
management  object  [AMO]  or  platfonn  object)  the  times  stamp  would  or  could  be  placed, 
and  (c)  it  was  not  clear  which  application  would  use  these  data  if  published. 

3.  AMO  publisher.  Each  application  was  to  have  an  AMO  integrated  into  its  component.  The 
AMO  is  an  important  test  component  that  supports  the  requirement  to  know  the  state  of  all  test 
assets  all  the  time. 

•  Most  test  centers  did  not  do  this;  instead,  a  separate  AMO  application  ran  on  the  same 
computer  running  the  “main”  application.  ATC  operated  the  AMO  separately  in  this  way, 
too,  by  running  a  separate  AMO  application  on  the  same  system  running  the  ADMAS 
SDO. 


5.  ATC  Accomplishments 


ATC  succeeded  in  producing  a  TENA  platform  object  complete  with  trans-location  of  the 
Aberdeen  Proving  Ground  (APG)  position  onto  the  WSMR  terrain  (the  ADMAS  SDO).  We 
were  not  able  to  read  these  vehicle  position  data  directly  from  ADMAS  or  the  vision  digital 
library  system  (VDLS).  Instead,  we  used  previously  logged  GPS  data  recorded  from  an 
ADMAS  device  that  was  mounted  on  a  Stryker  vehicle  driving  on  the  Perryman  test  course  at 
ATC. 
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5.1  TENA  Development  Workstation 

ATC’s  instrumentation  development  team  also  configured  a  VPG  team  computer  as  a  TENA 
development  workstation  in  the  Microsoft  Windows3  XP  environment 

5.2  AMO  Run  From  ATC 

Garry  Fee,  Electronic  Proving  Ground  (EPG),  Arizona,  developed  a  basic  AMO  publisher  and 
made  it  available  to  MS  4  participants.  This  AMO  SDO  was  run  as  a  separate  application  on  the 
same  computer  platform  used  to  run  the  ADM  AS  SDO.  The  AMO  SDO  contains  fields  for 
operator  point  of  contact  information  and  application  identifiers.  The  AMO  also  provided  a 
simple  “heartbeat”  and  diagnostic  data  designed  to  let  the  EPG  “Starship”  engine  know  the  status 
of  the  local  computer  system.  This  was  used  as  a  general  TENA  connectivity  test  since  each  test 
center  published  and  subscribed  to  the  AMO,  whereas  not  every  test  center  subscribed  to  specific 
commodity  area  objects.  For  example,  the  Redstone  Technical  Test  Center  (RTTC)  published  a 
radar  object  that  was  not  subscribed  to  by  other  test  centers;  ATC  published  vehicle  position  data 
within  the  “platform”  object,  which  were  not  subscribed  to  by  every  test  center. 

5.2.1  Starship  Run  From  ATC 

EPG  operated  Starship  (and  a  local  AMO  SDO  for  Starship)  from  the  ATC  distributed  test 
control  center  (DTCC).  These  applications  were  run  on  a  different  workstation  than  the 
ADMAS  SDO  and  ADMAS  AMO. 

Though  not  a  written  requirement,  the  ADMAS  AMO  SDO  is  intended  to  be  compiled  into  and 
become  a  part  of  the  main  application  which  would  then  fill  operator  point  of  contact  information 
and  application  identifier  and  other  meta-data  directly  ( 4 ).  This  was  not  achievable  within  the 
compressed  schedule;  therefore,  the  AMO  SDO  was  run  as  a  separate  application. 

5.3  Partial  Integration  Into  ATC’s  TENA  Data  Collection  and  Distribution  System 

Preliminary  steps  were  made  toward  integrating  the  ADMAS  SDO  with  the  existing  ATC  TENA 
system.  The  existing  system  applies  ADMAS  “live  feed”  vehicle  position  information  to 
workstations  running  an  ADMAS  SDO.  However,  the  existing  production  ADMAS  SDO  uses  a 
slightly  different  object  model  than  the  one  identified  for  DTE  ARCH  MS  4.  The  TENA  object 
model  identified  for  MS  4  is  shown  in  appendix  C.  The  preliminary  steps  taken  to  integrate  the 
MS  4  SDO  into  ATC’s  production  environment  involved  creating  XML  tags  in  an  ADMAS 
configuration  file  and  conforming  local  workstation  parameters  to  use  this  configuration  when 
the  TENA  application  is  launched.  This  was  constructed  as  a  separate  TENA  naming  service  so 
as  not  to  conflict  with  ATC’s  deployed  live  vehicle  position  display  system.  Further  steps  are 


Windows  is  a  trademark  of  Microsoft. 
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required  to  fully  integrate  the  new  DTE  ARCH  MS  4  object  model  and  trans-location.  These 
steps  are  outlined  in  section  6. 


6.  Recommendations  for  ATC 


The  MS  4  ADMAS  SDO  is  a  self-contained  TENA  simulation  component.  The  following  options 
are  recommendations  that  apply  software  reuse  and  integration  into  the  existing  production 
ADMAS  system  at  ATC. 

1.  Complete  the  object  model  “switcher”. 

This  is  needed  to  seamlessly  integrate  new  TENA  object  models  into  the  existing  ATC 
VDLS  TENA  system  that  is  used  to  transport  position  and  other  data  for  a  live  visual 
display  of  test  vehicles  on  a  24-hours-per-day  seven-days-a-week  (24/7)  basis.  It  is 
expected  that  future  object  model  changes  could  occur,  resulting  in  the  continued  need  for 
the  “switcher.” 

2.  Incorporate  the  ATC-to-WSMR  trans-location  routine  in  a  JAVA4-based  VDLS  data 
translator. 

This  will  provide  a  component  that  may  be  reused  for  future  exercises  or  tests. 

This  component  is  highly  specialized  for  the  following  reasons: 

a.  It  incorporates  a  WSMR  terrain  (though  this  is  read  as  an  open  flight  data  file,  and 
other  terrain  databases  could  be  substituted). 

b.  It  is  specific  to  the  Perryman  test  course  at  APG. 

Certain  constants  are  designed  into  the  source  code,  which  work  very  well  for  APG. 
However,  the  farther  a  vehicle  is  from  the  Perryman  test  course,  the  less  realistic  the 
translation  will  be  in  terms  of  relative  vehicle  orientation.  For  example,  a  vehicle  driving 
“north”  at  the  Perryman  test  course,  APG,  will  appear  to  drive  “north”  when  translated  to 
the  WSMR  terrain.  However,  if  the  vehicle  originated  at  the  Churchville  test  course  (about 
10  miles  away),  it  would  have  a  slight  offset  from  true  north  at  WSMR.  The  actual  offset 
and  its  significance  have  not  been  quantified.  The  recommendation  is  to  install  this  trans¬ 
location  algorithm  “as  is”  and  label  it  as  being  a  specific  Perryman  test  course-to-WSMR 
(at  some  latitude/longitude)  translation. 

c.  It  is  specific  to  the  WSMR  longitude  and  latitude  for  the  same  reasons. 


4JAVA,  which  is  not  an  acronym,  is  a  general  purpose,  high-level,  object-oriented,  cross-platform  programming 
language  developed  by  Sun  Microsystems. 
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3.  Add  a  WSMR  map  to  the  ATC  test  vehicle  “viewer.” 

Add  a  map  view  for  the  trans-located  area  of  WSMR  to  the  current  ADMAS  vehicle  display 
system.  Also  add  a  larger  map  for  the  entire  WSMR. 


7.  Recommendations  for  DTE  Architecture  Execution  (not  ATC  specific) 


Immediately  following  the  exercise,  the  author  voiced  these  suggestions  to  the  other  test  center 
representatives.  More  recommendations  are  expected  following  a  complete  DTC  after-action 
review. 

1 .  Checklist:  A  checklist  of  requirements  should  be  prepared  as  a  prerequisite  for  distributed 
test  participation.  This  should  include  verification  of  firewall  configuration.  Test  centers  not 
completing  these  checks  should  be  barred  from  participation  (to  allow  them  to  focus  on 
completing  the  prerequisite). 

2.  Single  configuration  data  source:  VISION5  (Versatile  Infonnation  Systems  Integrated  On¬ 
line  Nationwide)/ Army  Knowledge  Online,  or  another  central  location  should  be  used  to  upload 
the  most  recent  version  of  important  documents  (such  as  firewall  configuration).  During  MS  4, 
some  documents  were  distributed  via  e-mail,  and  some  resided  on  VISION.  This  added  to  the 
confusion.  As  an  example,  ATC  was  operating  from  a  stale  document  resulting  in  a 
misconfigured  firewall. 


8.  Conclusions 


The  ADMAS  SDO  was  very  successfully  integrated  into  MS  4.  ATC  also  faithfully  populated 
the  platfonn  object  with  time  space  position  information  (TSPI).  Other  test  centers  were  only 
able  to  fill  platform  TSPI  with  “test  data”  that  were  geographically  meaningless.  The  TENA- 
compliant  OTB  was  able  to  view  our  vehicle  operating  on  top  of  the  WSMR  terrain  surface. 
This  was  an  accomplishment  since  OTB  will  not  display  entities  on  its  viewer  if  they  have 
miscalculated  coordinates  resulting  in  locations  “off  the  map.”  Considering  the  short 
development  time  (approximately  two  weeks),  this  can  be  viewed  as  highly  successful. 

With  a  similar  amount  of  effort,  the  trans-location  algorithm  (specific  to  ATC-WSMR)  can  be 
properly  integrated  into  ATC’s  production  system  for  future  reuse.  Adding  more  general 
worldwide  trans-location  capability  would  take  a  little  more  time. 


'’http://vision.atc.army.mil/ 
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9.  Epilogue 


DTE  ARCH  MS4  was  another  stepping  stone  toward  the  development  of  a  distributed  test 
capability  across  U.S.  Army  Test  and  Evaluation  Command  (ATEC).  Eventually,  there  should 
be  a  matrix  of  test  range  and  simulation  assets  organized  into  a  Department  of  Defense  (DoD) 
architecture  framework  to  better  enable  test  customers  to  map  their  requirements  to  existing  and 
needed  simulation  test  environment  capabilities.  This  work  began  with  the  VPG  project  within 
DTC.  From  DTC,  it  grew  to  receive  participation  from  the  other  Anny  Test  and  Evaluation 
Command  subordinate  commands  (Operational  Test  Command  and  Anny  Evaluation 
Command). 

Since  the  inception  of  VPG,  the  DoD  has  issued  Joint  Vision  2020.  In  this  strategic  planning 
guidance  (SPG),  the  need  for  a  framework  to  describe  test  capabilities  as  well  as  the  requirement 
stating  that  a  “persistent,  robust  modern  networking  infrastructure  for  systems  engineering, 
developmental  test  and  evaluation,  and  operational  test  and  evaluation  (OT&E)  (including  initial 
OT&E  (IOT&E))  must  be  developed  that  connects  distributed  live,  virtual,  and  constructive 
(LVC)  resources”  (5).  The  cross-command  collaboration  effort  (3CE)  is  an  Anny  project 
between  ATEC,  RDECOM,  and  TRADOC  with  many  of  the  Joint  Vision  2020  objectives.  A 
DoD  Joint  Projects  Office  (JPO)  T&E  project  that  supports  these  objectives  is  currently  in  the 
feasibility  study  phase  this  year.  This  project  is  initially  called  the  Joint  Test  and  Evaluation 
Methodology  (JTEM).  Many  current  VPG  architecture  and  other  efforts  are  being  aligned  with 
3CE.  For  example,  the  VPG  Synthetic  Environment  Focus  Group  Distributed  Test  Event-5 
(DTE-5)  that  is  being  concluded  August-September  2005  is  highly  integrated  with  many  3CE 
activities.  VPG  will  continue  to  coordinate  and  cooperate  with  3CE,  JTEM,  as  well  as  other 
efforts. 

Following  DTE  ARCH  MS4,  an  after-action  review  took  place  (February  2005).  Each  of  the  test 
centers  contributed  with  a  report  detailing  its  own  focused  lessons  relating  to  its  activities.  That 
final  report  combining  all  test  center  perspectives  may  not  ever  be  produced  because  of 
accelerated  DTE-5  and  3CE  architecture  activities.  Therefore,  this  report  is  being  published  to 
separately  document  activities  from  an  APG  perspective  and  attempt  to  make  the  reader  aware  of 
some  of  the  broader  issues. 
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Appendix  A.  ATC  Objectives  (and  other  test  center  narratives) 


These  are  the  narratives  provided  by  VPG  architecture  focus  group  POCs  from  each  test  center. 
Some  are  labeled  event  2.5,  yet  were  still  applied  for  event  4.0  (this  experiment). 

ATC  objectives: 

(ATC  Narrative) 

1.  Scenario  Narrative.  ATC  will  provide  live  test  data  collected  on  an  Aberdeen  Test  Center 
driving  course  to  support  the  DTE-ARCH  scenario.  This  data  will  represent  an 
individual  FCS  vehicle  surrogate  maneuvering  in  open,  flat  terrain.  The  source  data  will 
be  derived  from  a  live  test  run.  For  this  reason,  the  FCS  vehicle  surrogate  mission  will  be 
scripted.  The  APG  platform  will  represent  a  non-combat  vehicle  operating  along  a 
resupply  route  to  support  the  NLOS  battery.  OTB  will  subscribe  to  and  visualize  the 
platform  object  and  attribute  updates  which  are  translocated  to  WSMR  coordinates  and 
published  through  the  ATC  ADMAS  server. 

DTE-ARCH  Narrative 
FlightLab  -  Event  2.5 

In  event  2.5  ATTC  will  use  FlightLab  to  simulate  a  Blackhawk  helicopter.  The  purpose  of  the 
Blackhawk  helicopter  in  this  exercise  is  to  perform  BDA  and  will  involve  the  following  steps. 

1 .  The  Blackhawk  will  initially  be  stationed  at  a  predetennined  location  on  the  battlefield. 

2.  The  target’s  location  will  be  provided  prior  to  the  event. 

3.  When  the  target  has  been  fired  upon,  C2  Vehicle  will  provide  a  verbal  message  to 
FlightLab  to  commence  flying  to  target  and  perfonning  BDA  which  will  be  done  by 
attached  DIRSP. 

4.  During  event  2.5  FlightLab  will  publish  TSPI  info  (position,  velocity). 

5.  In  event  4  FlightLab  will  publish  AMO  info  and  subscribe  to  wind  speed  and  direction 
from  Wind  localclass,  target  location  from  SensorContact  message,  and  time  of  fire  from 
Cannon  message.  Some  may  be  implemented  but  not  promised  by  event  2.5. 

DTE-ARCH  Narrative 

EPG  Fort  Huachuca  -  Event  2.5 

In  the  Milestone  2.5  Event,  EPG  will  provide  an  Application  Management  Object  (AMO) 
publisher  application  and  subscriber  application  for  use  at  all  participating  test  sites.  The  AMO 
publisher  will  emulate  the  eventual  functionality  (slated  for  Milestone  4),  in  which  all 
participating  applications  will  publish  an  AMO.  The  AMO  subscriber  will  emulate  functionality 
served  by  Starship  (slated  for  1  February). 
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During  the  2.5  Event: 

•  Each  site  runs  an  instance  of  the  AMO  Publisher  Emulator  application; 

•  Those  sites  who  wish  to  subscribe  to  the  AMO  publication  will  run  an  instance  for  the 
AMO  Subscriber  Emulator  application; 

•  The  objective  is  for  participating  site’s  AMO  Subscriber  Emulator  application  to  see  the 
published  AMOs  from  all  other  sites. 

DTE-ARCH 
DIRSP  Component 

For  the  DTE-ARCH  event,  the  DIRSP  scene  generation  capabilities  will  be  used  to  simulate  a 
sensor  mounted  on  a  Blackhawk  helicopter.  The  sensor  will  perform  a  battle  damage  assessment 
role.  Inputs  will  include  platform  and  target  TSPI  updates.  The  sensor  will  be  controlled  by  an 
operator  using  a  joystick.  When  the  target  is  centered  in  the  crosshairs,  a  trigger  pull  event  by 
the  operator  will  prompt  the  publishing  of  target  position  data. 


WDTC  {West Desert  Test  Cell) 

DTE-ARCH  milestone  participation  for  Dugway  Proving  Grounds  (DPG),  Utah 

Milestone  2.5:  DPG  will  provide  wind  infonnation  consisting  of  direction  and  speed  for  a  given 
position.  Wind  direction  will  be  given  in  the  form  of  degrees  and  wind  speed  will  be  measured 
in  kilometers  per  hour.  The  weather  information  provided  will  cover  White  Sands  from  the 
location  of  latitude  32.05  north,  longitude  106.62  west  and  will  cover  approximately  60  km2. 
Weather  data  will  be  provided  at  one  kilometer  of  resolution  with  thirty-five  levels  of  elevation. 

Weather  data  provided  for  this  exercise  will  be  prerecorded  and  will  likely  be  data  from 
the  August/September  timeframe  of  2003. 

Milestone  4.0:  DPG  will  participate  in  the  same  manner  for  milestone  4  as  it  did  for  2.5  and 
further  provide  site  application  information  through  the  InterTec  AMO  model. 


DTE-ARCH  Narrative 
WSTC  -  Event  2.5 

In  event  2.5  ( White  Sands  Test  Cell)  WSTC  will  simulate  the  injection  of  a  live  asset  (DFCS 
target)  into  a  simulation  exercise  DTE-ARCH.  WSTC  will  build  a  TENA  application  that  will 
publish  a  Platform  Object  Model  (OM),  Application  Management  Object  (AMO)  and  subscribe 
to  a  Cannon  OM  to  determine  casualttyAssessmentStatus.  The  purpose  is  an  exercise  in 
live/virtual/constructive  environments.  WSTC’s  approach  will  involve  the  following  steps. 

6.  The  WSTC  application  (LiveTarget)  will  publish  the  AMO  on  startup.  For  this  exercise, 
the  update  rate  on  the  AMO  will  be  at  a  1  per  second  rate. 

7.  The  target’s  location  will  be  static  (non-moving)  during  the  exercise.  The  LiveTarget 
application  will  begin  publishing  the  Platform  OM  soon  after  startup.  The  Platform  OM 
will  be  updated  at  a  1  per  second  rate. 
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8.  The  LiveTarget  application  will  subscribe  to  the  Cannon  OM. 

9.  Upon  receipt  of  a  Cannon  OM  update,  the  LiveTarget  application  will  change 
casualtyAssessmentStatus  from  ALIVE  to  KILLCATASTROPIC. 

10.  Upon  completion  of  the  event,  all  publications  will  cease. 

In  addition  to  the  LiveTarget  application,  WSTC  will  help  in  the  coordination  &  planning  of  the 
event.  WSTC  is  researching  other  applications  (3D  viewers,  gateways,  and  such)  that  might  be 
brought  into  the  exercise. 

DTE- ARCH  Narrative 
YPG  Cannon  OM 

The  cannon  will  receive  “targeting  information”  from  the  controller.  On  receipt  of  the  targeting 
data,  the  Cannon  model  will  process  that  data  and  the  gun  will  be  “aimed”.  When  the  gun 
position  receives  the  “firing  clearance”,  the  gun  can  be  fired  at  the  target.  After  the  weapon  fires, 
the  data  for  chamber  pressure,  muzzle  velocity,  and  time  of  fire  will  be  returned  to  the 
subscribers. 
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Appendix  B.  Test  Scenario  Sequence 


This  test  scenario  sequencing  shown  in  table  B-l  defines  the  order  in  which  SDOs  were  to 
join  and  execute  certain  tasks  (6).  In  actuality  the  join  order  had  to  be  modified  by 
experimentation  because  of  connectivity  problems.  These  problems  resulted  in  applications 
being  suspended  (or  “hanging”,  being  paused  while  waiting  for  a  TENA  method  to  return 
control  to  the  calling  application).  By  trial  and  error  and  by  eventually  solving  most  of  the 
firewall  issues  a  successful  application  launch  sequence  was  determined. 

Reasons  for  applications  “ hanging  ”  were  not  immediately  determinable.  A  variety  of  factors 
contributing  to  this  are  discussed: 

A).  Improperly  configured  firewalls. 

B. )  Applying  the  TCP/IP  reliable  communication  option  for  TENA  data  transport 

This  could  result  in  waiting  for  a  response  and  eventual  time-out  when  connectivity  is 
disrupted. 

C. )  Differences  in  the  TENA  transport  option  used  by  each  application. 

For  example  there  was  not  a  constant  use  of  the  return  path  option:  -ORBlistenEndpoints 
iiop://aaa.bbb.ccc.ddd:portNum.  This  also  relates  to  firewall  configuration  since  some 
firewalls  will  block  data  returning  from  a  different  port.  It  was  agreed  that  each  test 
center  would  specify  the  port  for  the  received  data  via  the  TENA  ORBlistenEndpoints 
option  but  few  did. 

D. )  Differing  network  options  and  operating  systems  configurations  applied  by  the 
various  computers  involved.  The  was  a  mixture  of  Linux,  Microsoft  windows  2000,  and 
Microsoft  windows  XP  operating  systems.  By  default  XP  systems  implement  a  local 
firewall.  There  were  also  differences  between  distributions  within  those  systems  that  may 
have  had  an  impact.  For  example  Microsoft  service  pact  2  (SP2)  has  modified  windows 
in  the  following  ways  (7): 

1.  TCP  packets  may  no  longer  be  sent  through  the  raw  sockets  API 

2.  IP  “ spoofed ”  UDP  packets  may  no  longer  be  sent  through  raw  sockets  (affects 
decoy  and  spoofed  scanning). 

3.  Outbound  TCP  connection  attempts  are  artificially  reduced  to  a  slow  rate. 
Apparently  this  is  done  to  prevent  scanning  of  ports.  This  could  be  effecting  the 
TENA  communication  as  the  application  looks  for  an  available  port. 

Table  B-l  Formatting  Notes: 

Example  1:  “AMO-STARSHIP”  means  the  AMO  object  from  the  Responsible  Application 
of  “Starship.” 

Example  2:  “CANNON-TARGET”  means  the  CANNON  object  from  the  Responsible 
Application  of  “target.” 
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Table  B-l.  DTE  ARCH  Milestone  4,  Test  Scenario  Sequence  (source:  reference  5). 


Step 

Action 

Publisher 

Subscriber 

1. 

Test  is  initiated.  All  applications  up  and 
running. 

2. 

Applications  status  check, 

STARSHIP 

TARGET 

ADMAS 

CANNON 

4DWX 

FLIGHTLAB 

RADAR 

DIRSP 

OTB 

AMO-STARSHIP 

AMO-TARGET 

AMO-ADMAS 

AMO-CANNON 

AMO-4DWX 

AMO-FLIGHTLAB 

AMO-RADAR 

AMO-DIRSP 

AMO-OTB 

AMO-  STARSHIP 

3. 

OTB  subscribes  to  Target,  ADMAS, 
Cannon,  FlightLab,  Radar  and  DIRSP. 

PLATFORM-TARGET 

PLATFORM-ADMAS 

PLATFORM-CANNON 

PLATFORM-FLIGHTLAB 

PLATFORM-RADAR 

PLATFORM -DIRSP 

PL  ATF  ORM-OTB 

4. 

4DWX  publishes  wind  information  to 
FlightLab  for  the  duration  of  this 
scenario. 

WEATHERSERVER- 

4DWX 

WEATHERSERVER- 

FLIGHTLAB 

5. 

ADMAS  publishes  live  test  data  to 

Radar,  and  OTB  for  the  duration  of  the 
scenario 

PLATFORM-ADMAS 

PLATFORM-RADAR 

PLATFORM-OTB 

6. 

A  target  is  placed  at  WSMR. 

PLATFORM-TARGET 

7. 

C2 Vehicle  sends  a  VERBAL  command 
to  Radar  to  commence  target  searching. 

8. 

Radar  searches 

PLATFORM-RADAR 

9. 

Radar  Locates  target 

SENSORCONTACT- 

RADAR 

PLATFORM-OTB 

10 

Radar  sends  target  VERBAL  position 
data  back  to  C2Vehicle 

11 

C2 Vehicle  sends  VERBAL  targeting  data 
to  Cannon. 

12 

Cannon  receives  targeting  data  and  aims 
cannon  at  target. 

13 

When  given  clearance  by  C2  Vehicle, 
Cannon  fires. 

CANNON-CANNON 

CANNON-TARGET 

14 

After  Cannon  is  fired,  an 
acknowledgment  is  sent  to  C2Vehicle 

CANNON-TARGET 

CANNON-OTB 

CANNON-FLIGHTLAB 

15 

Cannon  data  is  sent  to  FlightLab  and 

OTB. 

PLATFORM-TARGET 

PLATFORM-FLIGHTLAB 

PLATFORM-OTB 

16 

C2 Vehicle  sends  a  VERBAL  message  to 
FlightLab  to  commence  flying  to  perform 
target  BDA. 

17 

DIRSP  identified  the  target. 

SENSORCONTACT -DIRSP 

18 

DIRSP  provides  range  and  position 
information  back  to  FlightLab. 

PLATFORM-FLIGHTLAB 

19 

FlightLab  sends  VERBAL  Battle 

Damage  Assessment  results  back  to 
C2Vehicle. 

20 

End  of  Scenario 
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Appendix  C.  DTE  ARCH  MS  4  Object  Model 


Figure  C-l  displays  the  DTE  ARCH  MS  4  object  model  that  includes  the  InterTech  AMO  object 
model.  Not  shown  is  the  ILH  object  model  and  its  components. 
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The  ILH  object  was  not  directly  addressed  in  the  report  body  since  ATC  did  not  incorporate  it 
into  the  ADMAS  SDO.  Its  purpose  is  to  provide  the  means  to  tag  simulation  and  test  data  to 
assist  in  its  storage  and  creating  an  automated  archive  reference  to  these  data  in  the  vision  digital 
library  system  (VDLS).  The  VPG  is  largely  a  product  of  the  VPG’s  Integrated  Infonnation 
Systems  (IIS)  Focus  Group.  The  ILH  data  model  is  incorporated  in  the  VLDS  data  structure. 
The  TENA  ILH  SDO  developed  by  the  RTTC  and  allows  an  operator  to  fill  ILH  fields  to  avoid 
mistakes  when  test  or  test  supporting  simulation  data  are  stored  and  their  references  registered  in 
the  VDLS. 

The  objective  goal  is  to  have  this  type  of  automated  data  archiving  support  built  into  M&S  test 
range  assets.  More  on  the  ILH  and  its  implementation  at  RTTC  is  described  elsewhere  (8). 
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Appendix  D.  Coding  the  ADMAS  SDO 


This  appendix  describes  the  software  coding  used  to  implement  major  componts  of  the  ADMAS 
SDO. 

Introduction 

Coding  of  the  TENA  platform  object  was  complete  to  include  the  APG  position  translocation  to 
the  WSMR  terrain.  This  final  product  is  called  the  ADMAS  SDO.  Even  though  this  was  called 
the  ADMAS  SDO,  it  was  not  actually  reading  live  position  updates  from  an  ADMAS  vehicle 
telemetry  device.  Instead  the  ADMAS  SDO  had  its  input  designed  to  read  vehicle  position 
(GPS)  updates  in  a  format  available  from  ADMAS.  ADMAS  GPS  output  was  recorded  during  a 
previous  live  exercise,  the  distributed  test  event  4  (DTE-4)  experiments.  These  captured  DTE  4 
data  were  recorded  from  a  live  Stryker  vehicle  on  the  ATC  Perryman  test  track.  The  overall 
DTE  4  experiment  is  described  elsewhere  (9,  10,  11,  12). 

The  vehicle  translocation  algorithm  applied  was  developed  by  Mr.  Anthony  Docimo,  ATC, 
during  DTE  4  (13).  This  algorithm  provided  very  good  results  for  the  specific  conditions  used 
(translating  vehicle  position  and  orientation  from  APG  to  the  WSMR). 

Objectives  for  a  future  ATC  ADMAS  system  should  include  improving  on  the  MS  4 
implementation  in  two  aspects: 

1)  A  general  translocation  algorithm  should  be  developed  for  any  two  world  ground 
positions. 

2)  The  ADMAS  SDO  should  be  integrated  into  the  ATC  instrumentation  and  data 
archiving  process  in  order  to  both  read  and  translocate  data  directly  from  the  vision 
digital  library  system  (VDLS),  and  to  read  ADMAS  GPS  data  from  a  live  vehicle 
feed.  Reading  live  vehicle  data  could  be  done  by  using  the  existing  ATC  Ground 
systems  TENA  object  (not  compatible  with  the  DTC  ARCH  MS  4  object  model 
(Appendix  C))  or  by  creating  a  TENA  object  model  that  bridges  the  two  object 
models.  There  are  many  other  bridging  solutions  including  publishing  the  data  on  to 
a  LAN  between  distinct  applications  (13).  The  best  solution  depends  on  latency, 
project  resources,  and  other  constraints. 

Coding 

The  ADMAS  AMO  was  created  on  the  TENA  development  workstation  that  was  configured  on  a 
Windows  XP  computer  with  the  remarkable  technical  assistance  of  ATC’s  instrumentation  team. 
All  directories  and  files  referenced  are  relative  to  their  location  on  that  that  windows  XP  computer. 
A  backup  of  all  the  files  was  created  prior  to  the  MS  4  event  and  is  located  in  the  author’s  personal 
workspace  on  the  vision  digital  library  system  (VDLS)  (http://vision.atc.army.mil). 
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TENA  auto-generates  all  necessary  underlying  middleware  required  for  SDO’s  to  communicate 
with  the  “logical  range”  (TENA  simulation  environment).  These  software  modules  are  code 
“stubs”  in  that  they  provide  the  interface  to  the  publish  data  to  and  read  data  from  the  object 
model.  It  is  up  to  the  programmer  to  implement  the  correct  behavior  that  goes  into  these  modules. 
Most  of  the  TENA  middleware  was  applied  as-is.  However,  scientists  at  the  Aberdeen  Test  Center 
(principally  Mr.  Alan  Scramlin)  had  designed  an  improvement  in  the  call  back  methods  to  the 
TENA  IKE  version  3  release.  This  improvement  was  implemented  from  the  necessity  of  operating 
with  vehicle  telemetry  being  received  24/7.  After  prolonged  operation  the  middleware  would 
become  locked.  This  issue  and  ATC’s  callback  redesign  was  made  known  to  the  TENA 
developers.  Specifically  this  involved  applying  standard  template  library  (STL)  maps  instead  of 
lists  and  disabling  the  default  callback  process.  As  mentioned  TENA  provides  most  middleware 
source  code,  however  to  implement  the  ATC  improvements,  seven  middleware  source  code  files 
are  modified.  They  are  all  of  the  basic  implementation  (Basiclmpl)  class,  the  source  files  are: 

Callbacklnfo.cpp 

DestructionCallbackFactorylmpl.cpp 

DestructionCallbackFactory.cpp 

DiscoveryCallbackFactorylmpl.cpp 

DiscoveryCallbackFactory.cpp 

StateChangeCallbackFactorylmpl.cpp 

Further  technical  details  are  not  within  the  scope  of  this  report.  However,  it  is  mentioned  here 
because  the  ADMAS  SDO  used  the  ATC  callback  system  to  be  most  compatible  with  ATC’s 
instrumentation  and  data  collection  processes.  A  user  application  will  not  be  effecting  in  that  it 
will  interface  to  the  same  API. 

Main  Platform  Application 

The  main  body  of  source  code  may  be  found  in  the  directory: 

C:\TEN  A\ObjectModels-v4.0.4\Windows-XP-VC++-7.1-opt-mt\wsmr-DTE_ARCH_FULL-vl.2_Impl\main\ 

Files: 

publish  DTEPlatform. cpp 

publish  init  DTEPlatf ormAttributes . cpp 

These  read  vehicle  position  updates,  transform  them  to  the  required  coordinates  and  publish  the 
vehicles  state  change.  PublishinitDTEPlatformAttributes.cpp  contains  the  main  initialization 
function  (initServant()).  This  is  used  to  initialize  the  entity  type  and  other  attributes  as  the  code 
portion  displayed  in  figure  D-l  shows. 

publishDTEPlatfonn.cpp: 
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DTE : : DTEPlatform: : ServantPtr  pDTEPlatf ormServant ( 

pServantFactory->createServantUsingDef aultFactory ( )  )  ; 

initServant (  pDTEPlatf ormServant  )  ; 


Figure  D-l.  Initializing  pDTEPlatformServant,  the  TENA  ADMAS  platform  object. 

After  initialization,  the  platform  object  merely  continues  to  receive  position  by  polling  them 
periodically  from  pseudo  ADMAS  interface.  They  are  automatically  translocated  to  be  on  the 
WSMR  location  when  obtained  from  the  ADMAS  interface.  The  translocation  algorithm 
developed  by  Docirno  (14)  was  wrapped  into  a  self  contained  routine.  Docimo’s  application  ran 
in  the  Linux  environment  and  used  shared  memory  and  sockets.  Shared  memory  and  socket  calls 
were  left  intact  and  commented  out  via  C-language  param  statements: 

#if def  _USES_SHEM 

The  rest  of  the  algorithm  and  open  flight  terrain  query  libraries  were  ported  to  the  WIN32 
environment  with  very  few  problems.  The  few  minor  changes  that  were  required  were 
embedded  within 

#ifdef  WIN32 

C-language  param  statements.  These  modified  files  are  located  in  the  c :  \admas\conv\  folder 
and  changes  where  made  to  the  source  code  files: 

dte4_legl . c 
trQuery . c 
terrain  .  c 
terrain  .  h 

Win32  gettimeofday . c 
Win32  gettimeofday . h 


(added) 

(added) 
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Intentionally  left  blank 
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List  of  Acronyms 


3CE 

cross-command  collaboration  effort 

ADMAS 

advanced  distributed  modular  acquisition  system 

AMO 

application  management  object 

APG 

Aberdeen  Proving  Ground 

ATC 

Aberdeen  Test  Center 

ATEC 

U.S.  Army  Test  and  Evaluation  Command 

DoD 

Department  of  Defense 

DTC 

Developmental  Test  Command 

DTCC 

distributed  test  control  center 

DT&E 

development,  test,  and  evaluation 

DTE-ARCH 

Distributed  Test  and  Evaluation  Architecture 

EPG 

Electronic  Proving  Ground 

GPS 

global  positioning  system 

JPO 

Joint  Projects  Office 

JTEM 

joint  test  and  evaluation  methodology 

LVC 

live,  virtual,  and  constructive 

OT&E 

operational  test  and  evaluation 

OTB 

OneSAF  test  bed  baseline 

RDECOM 

U.S.  Army  Research,  Development  and  Engineering  Command 

RTTC 

Redstone  Technical  Test  Center 

SDO 

stateful  distributed  object 

SPG 

strategic  planning  guidance 

T&E 

test  and  evaluation 

TC 

test  center 

'TENA 

Test  and  Training  ENabling  Architecture 

TRADOC 

U.S.  Army  Training  and  Doctrine  Command 

TSPI 

time  space  position  information 

VDLS 

vision  digital  library  system 

VPG 

Virtual  Proving  Ground 

WSMR 

White  Sands  Missile  Range 
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